Computers communicate with each other for a variety of reasons. For example, a user on one computer may wish to send a message (e.g., an email) to a user on a remote computer or to retrieve a Web page from a remote computer. A client computer system can identify and communicate with millions of other computer systems on the Internet by using a unique network address for each such computer. A common type of network address is a unique numeric identifier called an “IP address” (e.g., 198.81.209.25). Each computer also typically has a unique textual Domain Name System (DNS) domain name network address (e.g., “micron.com” or “comp23.MicronPC.com”) that is mapped to that IP address.
When a communication is sent from a client (or “source”) computer system to a server (or “destination”) computer system, the client computer system typically specifies the IP address of the server computer system (either directly or via a domain name that maps to the IP address) in order to facilitate the routing of the communication to the server computer system. Such communications typically take place using the TCP/IP network communications protocol. For example, common application-level communications protocols such as HTTP, FTP, Telnet, and Simple Mail Transfer Protocol (SMTP) typically use TCP/IP as an underlying communications mechanism. The TCP/IP protocol is described in greater detail in “TCP/IP Network Administration, Second Edition” by Craig Hunt, 1992, O'Reilly & Associates Publishing, which is hereby incorporated by reference in its entirety.
Application programs executing on different computers often communicate by using communication mechanisms provided by the operating systems on their computers. For example, application programs commonly exchange information using TCP/IP communication sockets that are provided by operating systems such as Unix or Microsoft Windows. A socket connection can be described with four pieces of information, those being a source computer IP address and software port and a destination computer IP address and software port. Such a socket connection is typically initiated by an application program executing on a server computer. In particular, a server application creates a socket on the server (e.g., via the “socket” function), binds the server computer IP address and the software port to the socket (e.g., via the “bind” function), and obtains a software port on the server which is mapped to the server application by the server's operating system. The server application then listens for a connection request from a client computer (e.g., via the “listen” function) that includes a source IP address and software port to which the server application can respond.
When a client application program wants to communicate with such a server application, the client application creates a socket on the client (via the “socket” function) and may determine a client computer software port that is to be mapped to the client application. The client application then specifies that the created socket has a destination IP address corresponding to the destination computer and a destination software port that corresponds to the port mapped to the server application program, and uses the socket to make a connection request to the server application (e.g., via the “connect” function). In particular, the connection request is transmitted to the destination IP address and software port, along with the source IP address and software port to allow the server to respond. The inclusion of the source IP address with the connection request can be performed by the client computer operating system, which determines the IP address for the computer on which the client application is executing (e.g., by using the routing table or some other mechanism on the client computer).
The connection request that is sent to the destination IP address and software port is routed to the executing server application, and the application program on the server computer can then accept the connection request (e.g., via the “accept” function) and use the included source IP address and software port to respond to the client application. After the connection is accepted, the two programs can establish a shared communications standard and exchange information. TCP/IP sockets are described in greater detail in “Pocket Guide to TCP/IP Sockets (C Version)” by Kenneth L. Calvert and Michael J. Donaho, 2000, Morgan Kaufmann Publishers, which is hereby incorporated by reference in its entirety.
The Sendmail mail transport agent program is one example of software that communicates in the manner described above. For example, consider a situation in which a user on a client computer creates an email message using a mail user agent program (e.g., elm or Zmail) and specifies that a user on a remote server computer is to be a recipient of the email. The client mail user agent program begins the transfer of the created email to the remote recipient by forwarding the email to a local mail transport agent program (e.g., Sendmail or Zmailer) that is executing on the client computer. A copy of the mail transport agent may already be executing, or the mail user agent may instead invoke the mail transport agent. It is the responsibility of the local mail transport agent to transfer the created email to the remote server computer. If the local mail transport agent is the Sendmail program, it next establishes a socket-based connection with a Sendmail mail transport agent program that is executing on the remote server computer, and sends the email to the server. In some situations, the Sendmail mail transport agent on the client computer will temporarily store the email in an outgoing email queue on the client computer before transferring the email to the server computer. After the mail transport agent on the server computer receives the email, it makes the email available to the remote user recipient, who can use a mail user agent program on the server computer to read the email. The Sendmail program is available at the time of this writing at “http://www.sendmail.org/”, and additional details about Sendmail are available in “sendmail, Second Edition” by Bryan Costales with Eric Allman, 1997, O'Reilly & Associates Publishing, which is hereby incorporated by reference in its entirety.
FIGS. 1A-1E provide an illustrative example of email communications using the Sendmail program. In particular, FIG. 1A illustrates four computing devices that are accessible to each other over a network 190, with each of the computing devices using the Sendmail program (not shown) as their mail transport agent. Each computing device has a distinct assigned IP address 104 and a distinct DNS domain name 102 that is mapped to the assigned IP address. Each of the computing devices also have various users that have access to the computing device (e.g., by having user accounts on the device), with computing devices 100 and 130 each illustrating a list of defined users 106. In the illustrated embodiment, user a1 on computing device 100 will send an email to remote user x1 on computing device 130.
FIG. 1B illustrates an example email that is generated by user al using a local mail user agent program on computing device 100. Each email consists of a header portion 140 and a body portion 150, with the header portion including various information about the email and the body portion including the contents of the email. The illustrated email header currently includes 4 header lines 141-144 with header names “Date”, “From”, “To”, and “Subject”. Those skilled in the art will appreciate that a variety of other header lines can optionally be present.
FIG. 1C illustrates the same email after it is transferred to the local Sendmail program executing on computing device 100 for transmittal to computing device 130. As is illustrated, the local Sendmail program adds header lines 145 and 146 to the email message. Header line 145 indicates the sending user and the domain name of the sending computer, and header line 146 includes a unique message identifier for the email. In other situations, the local mail user agent may have already added these header lines when the email was generated, and if so the Sendmail program would not add them.
FIG. 1D illustrates the email as it is modified by the remote Sendmail program executing on computing device 130. In particular, when the remote Sendmail program receives the email, it adds a header line 147 to the email that indicates information about where the email was received from and when the email was received. In the illustrated embodiment, the header line 147 includes both the domain name (i.e., “abc.com”) and IP address (i.e., “216.122.95.01”) of the computing device from which the email was received.
FIG. 1E illustrates the communication that occurs between the two executing Sendmail programs when transferring the email. The two programs communicate using the SMTP communications protocol over TCP/IP sockets. In the illustrated embodiment, the communications from the local client Sendmail executing on computing device 100 are prefaced with “>>>” characters that are not actually transmitted but are shown here for the purposes of distinguishing these communications from those of the remote server Sendmail executing on the computing device 130. As shown in lines 161 and 162, the client Sendmail provides its domain name as part of the connection sequence, and the server Sendmail responds with a confirmation of the domain name identification.
Unfortunately, problems can arise when one computing device must communicate with other computing devices on behalf of a third-party. One reason that such problems can arise stems from the existence of malicious users that intentionally attempt to disguise the identity of themselves and their computing devices in a variety of ways, such as by having their computing devices transmit false domain name or IP address information for identification purposes (referred to as “IP spoofing”). In order to combat such malicious users, many computing devices and application programs have incorporated security measures to attempt to detect and/or prevent such malicious users and their computing devices from establishing connections. In particular, such security measures attempt to verify in various ways that the identification information provided by client computers is accurate. However, such security measures may also detect and/or prevent situations in which a computing device is legitimately acting on behalf of a third-party, such as when the computing device provides identification information that corresponds to the third-party.
As an example of a problem that arises when a computing device attempts to legitimately communicate with other computing devices on behalf of a third-party, consider the illustrative situation shown in FIG. 2A. In this situation, computing device 100 is acting as a shared host for four virtual computing devices (“VCDs”) 200, 210, 220, and 230, also referred to as “virtual machines” or “virtual computers”. Each VCD has distinct virtual network address information, including a distinct DNS domain name 202 and a distinct virtual IP address 204, as well as one or more defined virtual users 206. As with other domain names, the domain name of a VCD is mapped to the virtual IP address of that VCD (e.g., “bcd.com” is mapped to “216.122.95.70”). An owner of a computing device may allow it to act as a host for multiple VCDs or virtual IP addresses for a variety of reasons, such as if the hosting is a service that the owner provides to the domain name or VCD owners for a fee.
While the VCDs are not actual physical devices, they do share the resources of computing device 100 (e.g., memory, storage, and processing power) and can appear to their users as if they were physical devices. For example, user b1 of VCD 200 may be physically using the I/O devices of computing device 110, but may remotely login to VCD 200 (e.g., by using a Telnet program or Web browser) and gain access to the resources of VCD 200. Once access has been gained, user b1 can typically then perform the same types of actions as non-virtual users (e.g., user al) of computing device 100, such as executing programs or modifying the contents of VCD 200's storage (e.g., storage of computing device 100 that is allocated to VCD 200). In addition to receiving access to computing device 100 resources, the virtual IP addresses of the VCDs are mapped to computing device 100 so that communications sent to those virtual IP addresses will be forwarded to the device in the same manner as communications sent to the device's actual IP address of “216.122.95.01”.
As with non-virtual computing devices, the VCDs may need to communicate with other computing devices. For example, user b1 of VCD 200 may wish to send email to user x1 of computing device 130. In order to do so, however, the physical resources of computing device 100 will need to be used, with computing device 100 acting on behalf of VCD 200. Unfortunately, as indicated above, security measures employed by other computing devices or application program may detect and/or prevent such communication by computing device 100 despite the fact that it is acting legitimately on behalf of the third-party VCD 200.
FIGS. 2B-2E illustrate an example of virtual user b1 of VCD 200 sending email to user x1 of computing device 130 using the Sendmail program as the mail transport agent, and of problems caused by security measures employed by the Sendmail program (which is responsible in this example for the inter-computer communication). In particular, FIG. 2B illustrates an example email that is generated by user b1 using a local mail user agent program on VCD 200. This email is similar to that illustrated in FIG. 1B, with the exception that header line 242 identifies the sender as being a user of the “bcd.com” domain name for VCD 200 rather than the “abc.com” domain name for computing device 100. FIG. 2C illustrates the email after it is transferred to a local Sendmail program executing on VCD 200, such as by invoking the program. As with FIG. 1C, the local Sendmail program adds header lines 245 and 246 to the email message, but the header lines in this example also use the “bcd.com” domain name rather than computing device 100's “abc.com” domain name.
FIG. 2D illustrates the email as it is modified by the remote Sendmail program executing on computing device 130. In particular, the remote Sendmail program adds a header line 247 to the email that indicates information about where the sender of the email. However, as is illustrated in FIG. 2D (in bold for the sake of clarity), the remote server Sendmail identifies the domain name and IP address of the sending computing device to be that of the physical device used for the sending (i.e., “abc.com” and “216.122.95.01”) rather than those of the VCD which was responsible for sending the email. The communication that occurs between the two executing Sendmail programs, shown in FIG. 2E, illustrates the same problem. In particular, as shown in line 261, the client Sendmail provides an indication that its domain name is “bcd.com”. The server Sendmail believes the actual domain name of the client to be “abc.com”, however, based on examining the IP address from which the communication request was made and mapping the IP address to its domain name. The server Sendmail indicates the inconsistency between the indicated domain name of the client and what it believes to be the true domain name in line 262 by including the true domain name in parentheses (illustrated in bold for the sake of clarity). The server Sendmail also adds an entry to an Error file indicating that the host “abc.com” claimed to be “bcd.com”.
The misidentification of the email sender in the illustrated situation is caused by Sendmail's use of the standard socket network communications mechanism. In particular, even if the Sendmail program is invoked by another program executing in VCD 200 such as a mail user agent, the Sendmail program needs to have unrestricted access to various resources of computing device 100 and thus needs to execute with the highest level of system administrator privileges for computing device 100 (e.g., the “root” user for a Unix system). When the operating system of computing device 100 determines the network address information that corresponds to the socket created by the Sendmail program, it determines that the Sendmail program is executing for a user of computing device 100 having system administrator privileges and it retrieves the network address information for computing device 100. In this manner, the network address information of computing device 100 gets provided for the created socket rather than the network address information of VCD 200. Those skilled in the art will appreciate that a similar problem could occur for various other reasons in other situations. For example, if computing device 100 provided a single executing copy of a network communications program that processed the communications requests for all of the application programs running on the VCDs, that executing program may similarly use the network address information for computing device 100 rather than for any particular user or VCD executing an application program.
Unfortunately, the misidentification of the email sender in the illustrated situation can cause various problems. Depending on the configuration of the remote mail transport agent, such an email may not even be accepted. Moreover, even if the email is accepted and provided to user x1, the email will contain inconsistent information about the sender. In particular, header line 247 indicates that the email came from a user at a device with a domain name of “abc.com” and an IP address of 216.122.95.01, while header lines 242, 245 and 246 indicate that the email came from a user at a device with a domain name of “bcd.com” and an IP address of 216.122.95.70. Such inconsistent information can cause the recipient of the email to distrust the email or refuse to accept it. For situations in which a company is providing hosting services to customers, such problems can cause loss of business and other problems. Moreover, those skilled in the art will appreciate that these problems are not limited to email messages, and can instead occur for any type of inter-computer communication.
Thus, a need exists for a computing device that is acting legitimately on behalf of third-parties (e.g., a computing device acting as a host to VCDs or to virtual network addresses) to be able to communicate with other computing devices for those third-parties without triggering security measures employed by those other computing devices.